******************************************************************************
******************************************************************************

BIRD ID#:        XXX
ISSUE TITLE:     Package Modeling with ICM
REQUESTER:       Michael Mirmak, Intel Corp.
DATE SUBMITTED:  January 18, 2008
DATE REVISED:    
DATE ACCEPTED BY IBIS OPEN FORUM:  PENDING

******************************************************************************
******************************************************************************

STATEMENT OF THE ISSUE:

The IBIS specification, versions 1.1 through 4.2, includes a native package 
modeling format which extends package representations beyond lumped 
parameters.  This native format can describe package interconnects through 
multi-segment uncoupled topologies or through a single matrix for coupling
information.  This native format assumes that the [Pin] keyword describes 
and assigns 1-to-1 connections between buffers ([Model]s) and pins.

The ICM (IBIS Interconnect Modeling) Specification was introduced in 2003 to
permit modeling of more complex packages, including lossy coupled and
frequency-domain descriptions.  No explict links between IBIS and ICM exist at
this time in either specification. 

The IBIS 4.1 specification, under the [Circuit Call] keyword definition, 
includes references to a "non-native package model" format.  This format was 
intended to enable explicit (named) connections of die pads to package pins, 
as well as to permit package routing topologies not possible using IBIS 
[Package Model] syntax (e.g., connecting multiple die pads to a single 
package pin).

At the time of adoption of IBIS 4.1, the details of this "non-native" format 
were not decided and ICM was not an official specification.  Additionally, the 
specific method for attaching "non-native" package models to IBIS was unknown.  
As a result, the IBIS 4.1 parser does not support models which rely on package 
connections under this "non-native" format.

This BIRD updates the IBIS specification to support ICM as the "non-native"
format described in IBIS 4.1.  ICM support is enabled here under both the 
multi-lingual and "native" IBIS approaches.  This update also enables multi-
lingual IBIS [Component]s to use multiple package connections to a single pin and/or a 
single buffer.  Note that this BIRD changes little about the actual syntax of
IBIS, but implies that additional checking of referenced ICM files is required
to ensure correct linking of ICM and IBIS files.

******************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

All changes, with the exception of spacing and line break adjustments, are 
shown with |*.

|*****************************************************************************
|* ORIGINAL [PACKAGE MODEL] TEXT
|*****************************************************************************
|=============================================================================
|     Keyword:  [Package Model]
|    Required:  No
| Description:  Indicates the name of the package model to be used for the
|               component.
| Usage Rules:  The package model name is limited to 40 characters.  Spaces
|               are allowed in the name.  The name should include the company
|               name or initials to help ensure uniqueness.  The EDA tool
|               will search for a matching package model name as an argument
|               to a [Define Package Model] keyword in the current IBIS file
|               first.  If a match is not found, the EDA tool will next look
|               for a match in an external .pkg file.  If the matching package
|               model is in an external .pkg file, it must be located in the
|               same directory as the .ibs file.  The file names of .pkg files
|               must follow the rules for file names given in Section 3,
|               GENERAL SYNTAX RULES AND GUIDELINES.
| Other Notes:  Use the [Package Model] keyword within a [Component] to
|               indicate which package model should be used for that
|               component.  The specification permits .ibs files to contain
|               [Define Package Model] keywords as well.  These are described
|               in the "Package Modeling" section near the end of this
|               specification.  When package model definitions occur within a
|               .ibs file, their scope is "local", i.e., they are known only 
|               within that .ibs file and no other.  In addition, within that
|               .ibs file, they override any globally defined package models
|               that have the same name.
|-----------------------------------------------------------------------------
[Package Model]     QS-SMT-cer-8-pin-pkgs
|
|*****************************************************************************
|* ORIGINAL [CIRCUIT CALL] DESCRIPTION TEXT
|*****************************************************************************

| Port_map:
|
| The Port_map subparameter is used to connect the ports of an
| [External Circuit] to die nodes or die pads.
|
| Every occurrence of the Port_map subparameter must begin on a
| new line and must be followed by two arguments, the first
| being a port name, and the second being a die node, die pad,
| or a pin name.
|
| The first argument of Port_map must contain a port name that
| matches one of the port names in the corresponding [External
| Circuit] definition. No port name may be listed more than
| once within a [Circuit Call] statement. Only those port names
| need to be listed with the Port_map subparameter which are
| connected to a die node or a die pad. This includes reserved
| and/or user-defined port names.
|
| The second argument of the Port_map subparameter contains
| the name of a die node, die pad, or a pin. The names of die
| nodes, die pads, and pins may appear multiple times as
| Port_map subparameter arguments within the same [Circuit
| Call] statement to signify a common connection between
| multiple ports, such as common voltage supply.
|
| Please note that a pin name in the second argument does not
| mean that the connection is made directly to the pin. Since
| native IBIS does not have a mechanism to declare die pads
| explicitly, connections to die pads are made through their
| corresponding pin names (listed under the [Pin] keyword).
| This convention must only be used with native IBIS package
| models where a one-to-one path between the die pads and pins
| is assumed. When a package model other than native IBIS is
| used with a [Component], the second argument of Port_map must
| have a die pad or die node name. These names are matched to
| the corresponding port name of the non-native package model by
| name (not by position). In this case, the package model may
| have an arbitrary circuit topology between the die pads and
| the pins. A one-to-one mapping is not required.
|-----------------------------------------------------------------------------
| Examples:
|-----------------------------------------------------------------------------
|
| NOTE REGARDING THIS EXAMPLE:
| The pad_* to pin connections in Figure 12 and in the example
| lines with the comment, "explicit pad connection", are shown for
| reference. The connection syntax has not yet been defined.
| Therefore, the connections for pad_* to pin are not supported
| in this specification.
|
| For the examples below please refer to the following diagram and the
| example provided for the [Node Declarations] keyword.
|
|                                          Component Die   Package  Pins/balls
|-------------------------------------------------------+ +-------+
|                                                       | |       |
|  [E.Circuit]                   [E.Circuit]            | |       |
| +-------------------------+   +--------------+        | |       |
| | Model_A         A_mypcr-+-a-+-vcca1    vcc-+-10-----+-+--@@@--o 10 Vcc
| |         |\      A_mypur-+-b-+-vcca2        |        | |       |
| |D_drive--| >---+-A_mysig-+-c-+-int_ioa  io1-+-1------+-+--@@@--o 1 Buffer A
| |D_enable-|/ /| | A_mypdr-+-d-+-vssa1        |        | |       |
| |D_receive--< |-+ A_mygcr-+-e-+-vssa2    gnd-+-pad_11-+-+--@@@--o 11 GND
| |            \|           |   |              |        | |       |
| +-------------------------+   |     Die_     |        | |       |
|                               | Interconnect |        | |       |
|  [E.Circuit]                  |              |        | |       |
| +-------------------------+   |              |        | |       |
| | Model_B                 |   |              |        | |       |
| |         |\      A_mypur-+-f-+-vccb1        |        | |       |   Self Ad-
| |D_drive--| >-----A_mysig-+-g-+-int_ob    o2-+-pad_2a-+-+-@@@-+-o 2 justing
| |         |/      A_mypdr-+-h-+-vssb1        |        | |     | |   Buffer
| |          |A_mycnt       |   |              |        | |     | |
| +----------+--------------+   +--------------+        | |     | |
|            | Analog Buffer Control                    | |     | |
|            +-----------------------------------pad_2b-+-+-@@@-+ |
|                                                       | |       |
|      [E.Circuit]                                      | |       |
|     +--------------------------+                      | |       |
|     | Model_C          A_mypcr-+-10---(to pin/pad 10) | |       |
|     |          |\      A_mypur-+-10---(to pin/pad 10) | |       |
| nd1-+-D_mydrv--| >---+-A_mysig-+-3--------------------+-+--@@@--o 3 Buffer C
|  |  | D_enable-|/ /| | A_mypdr-+-pad_11               | |       |
|  |  | D_receive--< |-+ A_mygcr-+-pad_11               | |       |
|  |  |             \|           |                      | |       |
|  |  +--------------------------+                      | |       |
|  |                                                    | |       |
|  |   [E.Circuit]                                      | |       |
|  |  +--------------------------+                      | |       |
|  |  | Model_D                  |                      | |       |
|  |  |             /|   A_mypcr-+-10---(to pin/pad 10) | | +-@@@-o 4a Clocka
| nd1-+-D_receive--< |---A_mysig-+-pad_4----------pad_4-+-+-+     |
|     |             \|   A_mygcr-+-pad_11               | | +-@@@-o 4b Clockb
|     +--------------------------+                      | |       |
|                                                       | |       |
|      [E.Model] inside [Model]                         | |       |
|     +-----------------------------+                   | |       |
|     | Model_E             A_pcref-+->                 | |       |
|     |          |\         A_puref-+->                 | |       |
|     | D_drive--| >---+---A_signal-+-------------------+-+--@@@--o 5 Buffer E
|     | D_enable-|/ /| |    A_pdref-+->                 | |       |
|     | D_receive--< |-+    A_gcref-+->                 | |       |
|     |             \|---A_external-+->                 | |       |
|     |                       A_gnd-+->                 | |       |
|     +-----------------------------+                   | |       |
|-------------------------------------------------------+ +-------+
|
| Notes:
| 1) The ports of the [External Model] E are automatically connected by
| the tool, taking the [Pin Mapping] keyword into consideration, if exists.
| 2) The package model shown in this drawing assumes the capabilities of a
| non-native IBIS package model are available to the model author.
|
| Figure 12
|
|
[Circuit Call] A                  | Instantiates [External Circuit] named "A"
| 
Signal_pin 1
| 
| mapping  port          pad/node
|
Port_map   A_mypcr       a        | Port to internal node connection
Port_map   A_mypur       b        | Port to internal node connection
Port_map   A_mysig       c        | Port to internal node connection
Port_map   A_mypdr       d        | Port to internal node connection
Port_map   A_mygcr       e        | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] B                  | Instantiates [External Circuit] named "B"
| 
Signal_pin 2
| 
| mapping  port          pad/node
|
Port_map   A_mypur       f        | Port to internal node connection
Port_map   A_mysig       g        | Port to internal node connection
Port_map   A_mypdr       h        | Port to internal node connection
Port_map   A_mycnt       pad_2b   | Port to explicit pad connection
|
[End Circuit Call]
|
|
[Circuit Call] C                  | Instantiates [External Circuit] named "C"
| 
Signal_pin 3
| 
| mapping  port          pad/node
|
Port_map   A_mypcr       10       | Port to implicit pad connection
Port_map   A_mypur       10       | Port to implicit pad connection
Port_map   A_mysig       3        | Port to implicit pad connection
Port_map   A_mypdr       pad_11   | Port to explicit pad connection
Port_map   A_mygcr       pad_11   | Port to explicit pad connection
Port_map   D_mydrv       nd1      | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] D                  | Instantiates [External Circuit] named "D"
| 
Signal_pin 4a 
|
| mapping  port          pad/node
|
Port_map   A_my_pcref    10       | Port to implicit pad connection
Port_map   A_my_signal   pad_4    | Port to explicit pad connection
Port_map   A_my_gcref    pad_11   | Port to explicit pad connection
Port_map   D_receive     nd1      | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] Die_Interconnect   | Instantiates [External Circuit] named
|                                   "Die_Interconnect"
| 
| mapping  port          pad/node
|
Port_map   vcc           10       | Port to implicit pad connection
Port_map   gnd           pad_11   | Port to explicit pad connection
Port_map   io1           1        | Port to implicit pad connection
Port_map   o2            pad_2a   | Port to explicit pad connection
Port_map   vcca1         a        | Port to internal node connection
Port_map   vcca2         b        | Port to internal node connection
Port_map   int_ioa       c        | Port to internal node connection
Port_map   vssa1         d        | Port to internal node connection
Port_map   vssa2         e        | Port to internal node connection
Port_map   vccb1         f        | Port to internal node connection
Port_map   int_ob        g        | Port to internal node connection
Port_map   vssb1         h        | Port to internal node connection
|
[End Circuit Call]
|

|*****************************************************************************
|* END ORIGINAL TEXT
|*****************************************************************************

|*****************************************************************************
|* NEW [PACKAGE MODEL] TEXT
|*****************************************************************************
|
|=============================================================================
|     Keyword:  [Package Model]
|    Required:  No
| Description:  Indicates the name of the package model to be used for the
|               component.
|* Usage Rules:  Package models may be in IBIS or in ICM (IBIS Interconnect 
|*               Modeling) format.  The package model name is limited to 40 
|               characters.  Spaces are allowed in the name.  The name should 
|               include the company name or initials to help ensure uniqueness.  
|               The EDA tool will search for a matching package model name as 
|               an argument to a [Define Package Model] keyword in the current 
|               IBIS file first.  If a match is not found, the EDA tool will 
|               next look for a match in an external .pkg or .icm file.  If the 
|*              matching package model is in an external .pkg  or .icm file, it 
|*              must be located in the same directory as the .ibs file.  
|*               If both a .pkg and a .icm file containing a matching model
|*               are found, the .icm definition is assumed to take precedence.
|*              The file names of .pkg and .icm files must follow the rules for 
|               file names given in Section 3, GENERAL SYNTAX RULES AND GUIDELINES.
| Other Notes:  Use the [Package Model] keyword within a [Component] to
|               indicate which package model should be used for that
|               component.  The specification permits .ibs files to contain
|               [Define Package Model] keywords as well.  These are described
|*               in the Section 7, PACKAGE MODELING.  However, while ICM
|*               syntax may be used in external .icm files to describe package 
|*               models, ICM syntax is not permitted under the 
|*               [Define Package Model] keyword or anywhere else within an IBIS
|*               file.
|*
|*               When package model definitions occur within a
|               .ibs file, their scope is "local", i.e., they are known only 
|               within that .ibs file and no other.  In addition, within that
|               .ibs file, they override any globally defined package models
|               that have the same name.
|-----------------------------------------------------------------------------
[Package Model]     QS-SMT-cer-8-pin-pkgs
|
|*****************************************************************************
|* NEW [CIRCUIT CALL] TEXT
|*****************************************************************************
|
| Port_map:
|
| The Port_map subparameter is used to connect the ports of an
| [External Circuit] to die nodes or die pads.
|
| Every occurrence of the Port_map subparameter must begin on a
| new line and must be followed by two arguments, the first
| being a port name, and the second being a die node, die pad,
| or a pin name.
|
| The first argument of Port_map must contain a port name that
| matches one of the port names in the corresponding [External
| Circuit] definition. No port name may be listed more than
| once within a [Circuit Call] statement. Only those port names
| need to be listed with the Port_map subparameter which are
| connected to a die node or a die pad. This includes reserved
| and/or user-defined port names.
|
| The second argument of the Port_map subparameter contains
| the name of a die node, die pad, or a pin. The names of die
| nodes, die pads, and pins may appear multiple times as
| Port_map subparameter arguments within the same [Circuit
| Call] statement to signify a common connection between
| multiple ports, such as common voltage supply.
|
|* Note that a pin name in the third column does not
|* mean that the connection is made directly to the pin.  In
|* such a case, the die pad of the buffer connected to the pin
|* is named implicitly, by referring to the buffer's
|* corresponding pin name (listed under the [Pin] keyword).  In
|* other words, a pin name in the third column names a pad
|* which is associated to a [Pin] of the same name.  The interconnect
|* between the pad and [Pin] is defined by appropriate package
|* method: [Pin], [Package] or [Package Model].
|*
|* DELETE TEXT BELOW
|* Please note that a pin name in the second argument does not
|* mean that the connection is made directly to the pin. Since
|* native IBIS does not have a mechanism to declare die pads
|* explicitly, connections to die pads are made through their
|* corresponding pin names (listed under the [Pin] keyword).
|* This convention must only be used with native IBIS package
|* models where a one-to-one path between the die pads and pins
|* is assumed. When a package model other than native IBIS is
|* used with a [Component], the second argument of Port_map must
|* have a die pad or die node name. These names are matched to
|* the corresponding port name of the non-native package model by
|* name (not by position). In this case, the package model may
|* have an arbitrary circuit topology between the die pads and
|* the pins. A one-to-one mapping is not required.
|* END DELETION
|-----------------------------------------------------------------------------
| Examples:
|-----------------------------------------------------------------------------
|
|* DELETE TEXT BELOW
|* NOTE REGARDING THIS EXAMPLE:
|* The pad_* to pin connections in Figure 12 and in the example
|* lines with the comment, "explicit pad connection", are shown for
|* reference. The connection syntax has not yet been defined.
|* Therefore, the connections for pad_* to pin are not supported
|* in this specification.
|* END DELETION
|
| For the examples below please refer to the following diagram and the
| example provided for the [Node Declarations] keyword.
|
|                                          Component Die   Package  Pins/balls
|-------------------------------------------------------+ +-------+
|                                                       | |       |
|  [E.Circuit]                   [E.Circuit]            | |       |
| +-------------------------+   +--------------+        | |       |
| | Model_A         A_mypcr-+-a-+-vcca1    vcc-+-10-----+-+--@@@--o 10 Vcc
| |         |\      A_mypur-+-b-+-vcca2        |        | |       |
| |D_drive--| >---+-A_mysig-+-c-+-int_ioa  io1-+-1------+-+--@@@--o 1 Buffer A
| |D_enable-|/ /| | A_mypdr-+-d-+-vssa1        |        | |       |
| |D_receive--< |-+ A_mygcr-+-e-+-vssa2    gnd-+-pad_11-+-+--@@@--o 11 GND
| |            \|           |   |              |        | |       |
| +-------------------------+   |     Die_     |        | |       |
|                               | Interconnect |        | |       |
|  [E.Circuit]                  |              |        | |       |
| +-------------------------+   |              |        | |       |
| | Model_B                 |   |              |        | |       |
| |         |\      A_mypur-+-f-+-vccb1        |        | |       |   Self Ad-
| |D_drive--| >-----A_mysig-+-g-+-int_ob    o2-+-pad_2a-+-+-@@@-+-o 2 justing
| |         |/      A_mypdr-+-h-+-vssb1        |        | |     | |   Buffer
| |          |A_mycnt       |   |              |        | |     | |
| +----------+--------------+   +--------------+        | |     | |
|            | Analog Buffer Control                    | |     | |
|            +-----------------------------------pad_2b-+-+-@@@-+ |
|                                                       | |       |
|      [E.Circuit]                                      | |       |
|     +--------------------------+                      | |       |
|     | Model_C          A_mypcr-+-10---(to pin/pad 10) | |       |
|     |          |\      A_mypur-+-10---(to pin/pad 10) | |       |
| nd1-+-D_mydrv--| >---+-A_mysig-+-3--------------------+-+--@@@--o 3 Buffer C
|  |  | D_enable-|/ /| | A_mypdr-+-pad_11               | |       |
|  |  | D_receive--< |-+ A_mygcr-+-pad_11               | |       |
|  |  |             \|           |                      | |       |
|  |  +--------------------------+                      | |       |
|  |                                                    | |       |
|  |   [E.Circuit]                                      | |       |
|  |  +--------------------------+                      | |       |
|  |  | Model_D                  |                      | |       |
|  |  |             /|   A_mypcr-+-10---(to pin/pad 10) | | +-@@@-o 4a Clocka
| nd1-+-D_receive--< |---A_mysig-+-pad_4----------pad_4-+-+-+     |
|     |             \|   A_mygcr-+-pad_11               | | +-@@@-o 4b Clockb
|     +--------------------------+                      | |       |
|                                                       | |       |
|      [E.Model] inside [Model]                         | |       |
|     +-----------------------------+                   | |       |
|     | Model_E             A_pcref-+->                 | |       |
|     |          |\         A_puref-+->                 | |       |
|     | D_drive--| >---+---A_signal-+-------------------+-+--@@@--o 5 Buffer E
|     | D_enable-|/ /| |    A_pdref-+->                 | |       |
|     | D_receive--< |-+    A_gcref-+->                 | |       |
|     |             \|---A_external-+->                 | |       |
|     |                       A_gnd-+->                 | |       |
|     +-----------------------------+                   | |       |
|-------------------------------------------------------+ +-------+
|
| Notes:
| 1) The ports of the [External Model] Model_E are automatically connected by
| the tool, taking the [Pin Mapping] keyword into consideration, if exists.
|* DELETE TEXT BELOW
|* 2) The package model shown in this drawing assumes the capabilities of a
|* non-native IBIS package model are available to the model author.
|* END DELETION
|
| Figure 12
|
|
[Circuit Call] Model_A            | Instantiates [External Circuit] named "A"
| 
Signal_pin 1
| 
| mapping  port          pad/node
|
Port_map   A_mypcr       a        | Port to internal node connection
Port_map   A_mypur       b        | Port to internal node connection
Port_map   A_mysig       c        | Port to internal node connection
Port_map   A_mypdr       d        | Port to internal node connection
Port_map   A_mygcr       e        | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] Model_B            | Instantiates [External Circuit] named "B"
| 
Signal_pin 2
| 
| mapping  port          pad/node
|
Port_map   A_mypur       f        | Port to internal node connection
Port_map   A_mysig       g        | Port to internal node connection
Port_map   A_mypdr       h        | Port to internal node connection
Port_map   A_mycnt       pad_2b   | Port to explicit pad connection
|
[End Circuit Call]
|
|
[Circuit Call] Model_C            | Instantiates [External Circuit] named "C"
| 
Signal_pin 3
| 
| mapping  port          pad/node
|
Port_map   A_mypcr       10       | Port to implicit pad connection
Port_map   A_mypur       10       | Port to implicit pad connection
Port_map   A_mysig       3        | Port to implicit pad connection
Port_map   A_mypdr       pad_11   | Port to explicit pad connection
Port_map   A_mygcr       pad_11   | Port to explicit pad connection
Port_map   D_mydrv       nd1      | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] Model_D            | Instantiates [External Circuit] named "D"
| 
Signal_pin 4a 
|
| mapping  port          pad/node
|
Port_map   A_my_pcref    10       | Port to implicit pad connection
Port_map   A_my_signal   pad_4    | Port to explicit pad connection
Port_map   A_my_gcref    pad_11   | Port to explicit pad connection
Port_map   D_receive     nd1      | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] Die_Interconnect   | Instantiates [External Circuit] named
|                                   "Die_Interconnect"
| 
| mapping  port          pad/node
|
Port_map   vcc           10       | Port to implicit pad connection
Port_map   gnd           pad_11   | Port to explicit pad connection
Port_map   io1           1        | Port to implicit pad connection
Port_map   o2            pad_2a   | Port to explicit pad connection
Port_map   vcca1         a        | Port to internal node connection
Port_map   vcca2         b        | Port to internal node connection
Port_map   int_ioa       c        | Port to internal node connection
Port_map   vssa1         d        | Port to internal node connection
Port_map   vssa2         e        | Port to internal node connection
Port_map   vccb1         f        | Port to internal node connection
Port_map   int_ob        g        | Port to internal node connection
Port_map   vssb1         h        | Port to internal node connection
|
[End Circuit Call]
|
|*=============================================================================
|* NOTES ON CONNECTING IBIS AND ICM MODELS
|* IBIS Interconnect Modeling (ICM) Specification Models may be used as package
|* models, if the associated files are properly referenced under the [Package Model] keyword.
|* In order to assure correct connection of the model, a specific nodal
|* naming syntax must be followed.  Please refer to version 1.1 of the ICM
|* Specification for details on the ICM keywords mentioned below.
|*
|* In all cases described below, the IBIS [Component] that uses ICM to describe
|* its package interconnect simply includes a legal ICM filename under the [Package Model] keyword.
|* The named ICM file must include pins and/or nodes named according to the rules below
|* to ensure proper connections are made by the EDA tool.  Parsing by the ICM parser of
|* the calling IBIS file is not assumed.
|*
|* Connections Using [Pin] and [Model] without [External Model]
|*
|* Package connections using ICM between pins named under the IBIS [Pin] keyword and the individual
|* buffer pads used by instances of [Model] may be accomplished only implicitly, 
|* where a single buffer is assumed connected to the named pin without itself 
|* having a distinct name.
|*
|* Connections are made using the [ICM Node Map] or [ICM Pin Map] keywords.  A specific
|* [ICM Node Map]/[ICM Pin Map] keyword section must be present and match the [Pin]
|* list of the associated IBIS model by name.  Similarly, a specific
|* [ICM Node Map]/[ICM Pin Map] keyword section must be present and match the pad
|* names from the associated IBIS model by name.  Pad names are determined
|* from the [Pin] name.  
|*
|* Note that simply identifying the pad of interest is not sufficient to 
|* fully specify an interconnect definition.  As even traditional
|* IBIS models have ports for power, ground supplies, etc., the pad side
|* of the associated ICM model must also specify the IBIS port name of interest.
|* Therefore, the naming scheme in [ICM Pin Map]s to be used in connecting to IBIS is:
|*
|* a) The [ICM Pin Map] for the component side connecting to the external world uses IBIS [Pin] 
|*    names under the first (Pin) column
|* b) The [ICM Pin Map] for the die side of the component uses the syntax Pin_name.port_name, where
|*    the period character separates the IBIS pin name (which is an implied pad name in traditional 
|*    models) and the associated port_name or [Pin Mapping] rail (see below)
|*
|* Similarly, the naming scheme in [ICM Node Map]s to be used in connecting to IBIS is:
|*
|* a) The [ICM Node Map] for the component side connecting to the external world uses IBIS [Pin] 
|*    names under the first (Pin) column
|* b) The [ICM Node Map] for the die side of the component uses the syntax Pin_name.port_name, 
|*    where the period character separates the IBIS pin name (which is an implied pad name in 
|*    traditional models) and the associated port_name or [Pin Mapping] rail (see below)
|*
|* For the signal pad and only the signal pad, the .port_name portion of the [ICM Node Map] or [ICM Pin Map]
|* is omitted.
|*
|* Note that the IBIS [Pin] is matched to pin name (first column) and not the node name (second column) in [ICM Node Map].
|*
|* For both [ICM Node Map] and [ICM Pin Map], specific string arguments must be used as names in order 
|* to clearly identify the association between the IBIS and ICM nodes, pins and/or pads.  
|* The word "Die" must be used for the die pad side (buffer side) and "Pin" for the pin/ball side (connected
|* outside of the component).  The terms are case-sensitive.  
|*
|* The Side subparameter may be used but is not required.  Additional [ICM Node Map]s, [ICM Pin Map]s 
|* and/or Side subparameters will be assumed to be unconnected.
|*
|* Where [Pin Mapping] is used, the rails named there are assumed to be ideal or shorted 
|* connections between on-die nodes.  Therefore, the port_name used above must match the name
|* of a [Pin Mapping] rail in cases where ICM is used to model the package of an IBIS [Component]
|* using [Pin Mapping].
|* 
|* If [Pin Mapping] is not used, the supplies for individual models may still be connected to the ICM
|* package.  In this case, the "port_name" above must be one of the following strings:
|* pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref, ext_ref.  In this way, the supply nodes
|* for each model may be uniquely identified and connected through an ICM package.
|*
|* The ICM package does not have to connect to every port or pin described in the
|* IBIS component.
|*
|* Connections Using [Pin] and [Model] with [External Model]
|*
|* Connections of ICM to IBIS [Component]s featuring [External Model] calls are made in a similar
|* fashion to those involving traditional [Model]s. 
|*
|* Therefore, the naming scheme in [ICM Pin Map]s to be used in connecting to IBIS is:
|*
|* a) The [ICM Pin Map] for the component side connecting to the external world uses IBIS [Pin] 
|*    names under the first (Pin) column
|* b) The [ICM Pin Map] for the die side of the component uses the syntax Pin_name.port_name, where
|*    the period character separates the IBIS pin name (which is an implied pad name in traditional 
|*    models) and the associated port_name or [Pin Mapping] rail (see below)
|*
|* Similarly, the naming scheme in [ICM Node Map]s to be used in connecting to IBIS is:
|*
|* a) The [ICM Node Map] for the component side connecting to the external world uses IBIS [Pin] 
|*    names under the first (Pin) column
|* b) The [ICM Node Map] for the die side of the component uses the syntax Pin_name.port_name, 
|*    under the first (Pin) column, where the period character separates the IBIS pin name 
|*    (which is an implied pad name in traditional models) and the associated port_name or 
|*    [Pin Mapping] rail (see below)
|*
|* As above, for both [ICM Node Map] and [ICM Pin Map], specific string arguments must be used as names in order 
|* to clearly identify the association between the IBIS and ICM nodes, pins and/or pads.  
|* The word "Die" must be used for the die pad side (buffer side) and "Pin" for the pin/ball side (connected
|* outside of the component).  The terms are case-sensitive.
|*
|* Support for [Pin Mapping] with [External Model] is similar that for traditional [Model].  
|* Where [Pin Mapping] is used, the rails named there are assumed to be ideal or shorted 
|* connections between on-die nodes.  Therefore, the port_name used above must match the name
|* of a [Pin Mapping] rail in cases where ICM is used to model the package of an IBIS [Component]
|* using [Pin Mapping].
|* 
|* If [Pin Mapping] is not used, the analog ports for individual models may still be connected to the ICM
|* package.  In this case, the "port_name" above must be one of the following strings, corresponding to 
|* [External Model] reserved analog ports: A_puref, A_pcref, A_pdref, A_gcref, A_extref, A_gnd.
|*
|* Note that A_signal is assumed to be the signal pad itself.  Therefore, ICM connections to the signal pad omit
|* the .port_name syntax.  Similarly, A_pos, A_neg, A_signal_pos and A_signal_neg pads are connected
|* through the [Series Pin Mapping] and [Diff Pin] keywords, respectively.  These names should not be used
|* as .port_names in ICM syntax, as these additional keywords and their pin numbers alone are sufficient
|* to connect them.
|*
|* Digital ports cannot be connected to ICM packages.
|*
|* ICM may be used to define package models for IBIS [Component]s featuring a mix of [Model] only and
|* [External Model] definitions.  Care should be taken to avoid naming conflicts in such cases.
|*
|* Connections Using [External Circuit]
|*
|* ICM may be used to define package behavioral information for connections between
|* [External Circuit]s and [Pin]s, through the [Node Declarations] and [Circuit Call] keywords.  In
|* such cases, the pin names in the first column under [ICM Pin Map] must match
|* names under the third column of the [Circuit Call] Port_map section and, as appropriate, the 
|* [Node Declarations] keyword.  No additional restrictions are placed, for links to IBIS, on the 
|* string argument to [ICM Pin Map] or Pin_order.  The associated [ICM Pin Map] may be row- or
|* column-ordered.  Pin descriptions (the second column under [ICM Pin Map]) do not have any special 
|* meaning for connections to IBIS files.
|*
|* Therefore, the naming scheme in [ICM Pin Map]s to be used in connecting to IBIS is:
|*
|* a) The [ICM Pin Map] for the component side connecting to the external world uses IBIS [Pin] 
|*    names under the first (Pin) column
|* b) The [ICM Pin Map] for the die side of the component simply uses pad or node names under the 
|*    first (Pin) column, as used under the [Circuit Call] and [Node Declarations] keywords.  Names 
|*    that match [Pin] strings are assumed to be implicit pad connections, not IBIS [Pin] connections.
|*
|* Similarly, the naming scheme in [ICM Node Map]s to be used in connecting to IBIS is:
|*
|* a) The [ICM Node Map] for the component side connecting to the external world uses IBIS [Pin] 
|*    names under the first (Pin) column
|* b) The [ICM Node Map] for the die side of the component simply uses pad or node names under the 
|*    first (Pin) column, as used under the [Circuit Call] and [Node Declarations] keywords.  Names 
|*    that match [Pin] strings are assumed to be implicit pad connections, not IBIS [Pin] connections.
|*
|* As above, for both [ICM Node Map] and [ICM Pin Map], specific string arguments must be used as names in order 
|* to clearly identify the association between the IBIS and ICM nodes, pins and/or pads.  
|* The word "Die" must be used for the die pad side (buffer side) and "Pin" for the pin/ball side (connected
|* outside of the component).  The terms are case-sensitive.
|*
|* [Pin Mapping] is not supported in [Component]s featuring [External Circuit].
|* Therefore, power and ground supply nodes should be connected using ICM by name 
|* through [Node Declarations] and [Circuit Call], as detailed above.
|*
|* As with [External Model], under [External Circuit], digital ports cannot be connected to ICM packages.
|*
|* No mixing of ICM-based and non-ICM [Package Model]s (e.g., .pkg format), is permitted for the same
|* [Component[.  An IBIS component may use either one or the other, but not both. Package parameters
|* defined under [Pin] or [Package] may be used in the same [Component] as an ICM-based [Package Model].
|* In this case, the [Pin] and/or [Package] information applies where no ICM-based [Package Model]
|* information is provided; in cases where an ICM-based [Package Model] is defined, the ICM data overrides
|* the [Pin] and [Package] data.
|*
|*****************************************************************************
|* END NEW TEXT
|*****************************************************************************

******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION
[External Circuit] and associated keywords under IBIS 4.1 enable features 
such as external controllability of buffer behaviors through feedback.  To
make best use of these features in today's designs, package and on-die
interconnect models more complex than those supported by IBIS [Package
Model] were needed.  Of greatest need was the ability to connect multiple
die pads to a single external pin.  

At the time IBIS 4.1 was written, ICM was envisioned as the best method for
enabling these advanced features.  ICM had not been completed before IBIS 4.1 
was approved, so indirect references to ICM as a "non-native package model"
format were included in the 4.1 final document.  The authors assumed that
tools could connect ICM and IBIS models at the user level, and that new
IBIS syntax to support ICM to IBIS connections would be easily added.
The IBIS 4.1 specification also allowed explicit pad definitions within 
[Node Declarations] and Port_map. 

IBIS 4.1 parser development exposed several critical barriers to linking 
IBIS and ICM models.  The main issues involve the IBIS assumption of a 
"one-to-one" connection of die pads and pins, with the [Pin] keyword both 
explicitly defining pins and implicitly defining die pads.  

The changes above do not remove the 1-to-1 barrier for traditional IBIS.  
Existing IBIS files constructed using IBIS 4.1 rules do not in any way change 
in their interpretation with the introduction of explicit pad names.

Use of the [Package Model] and associated keywords ([Define Package Model], 
etc.) is never required.  

*****************************************************************************

ANY OTHER BACKGROUND INFORMATION:
From an informal suggestion by Arpad Muranyi, Intel Corp.

Several objectives helped define the structure of this BIRD:
- minimal changes to IBIS syntax
- minimal changes to ICM syntax
- continued support of [Pin Mapping] under traditional IBIS
- support for ICM under traditional IBIS, [External Model] and [External Circuit]
- support for single-pad, multi-pin and single-pin, multi-pad packages (e.g.,
  for stacked-die applications) through ICM

This last objective proved impossible to support using traditional IBIS structures
and ICM without major changes to long-standing keywords such as [Pin].  This 
BIRD therefore enables this last objective only for multi-lingual models.

The original IBIS specification text does not actually prohibit identical 
pin identifiers (identical first column entries) under [Pin].  This could cause
shorting issues unless an additional rule is created to handle it.

Note that [Pin], [Package] and [Package Model] interactions with IBIS 4.1
and 4.2 files are unaffected; the 1-1 assumption still applies in this case if
ICM is not used as the package model format, through implicit pins.  Explicit pin 
connections are, however, impossible using traditional IBIS package structures and
multi-lingual syntax.

An additional ICM requirement is defined here: in order to make IBIS and ICM work
together, the names "Pin" and "Pad" must be used for the relevant [ICM Pin Map] or
[ICM Node Map].  This ensures that EDA tools will properly associate the ICM
data endpoints in cases where node or pin names are identical.

[Alternate Package Models] is impacted by this BIRD, though no explicit changes
to the text of that keyword are necessary.  That keyword supports use of external
filenames as well as package model names internal to the calling IBIS file.

A summary chart of package and IBIS syntax combinations is included below.

IBIS and ICM Package Combination Decoder Ring

IBIS Type		Package Type	[Pin Mapping]?	Comment
Traditional		Traditional	No		Legal
Traditional		Traditional	Yes		Legal
Traditional		ICM		No		Legal - uses pulldown_ref, etc. names
Traditional		ICM		Yes		Legal - uses [Pin Mapping] rail names
[External Model]	Traditional	No		Legal - power supply connections ambiguous
[External Model]	Traditional	Yes		Legal - uses [Pin Mapping] rail names
[External Model]	ICM		No		Legal - uses [External Model] port names
[External Model]	ICM		Yes		Legal - uses [Pin Mapping] rail names
[External Circuit]	Traditional	No		Legal - some node connections ambiguous
[External Circuit]	Traditional	Yes		Illegal
[External Circuit]	ICM		No		Legal - uses [Circuit Call], [Node Declarations]
[External Circuit]	ICM		Yes		Illegal

******************************************************************************